-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[KOGITO-9980] Add persistence to SonataflowPlatform CRD #372
[KOGITO-9980] Add persistence to SonataflowPlatform CRD #372
Conversation
1ed9a32
to
809bc9b
Compare
test/testdata/platform/persistence/generic_from_platform_cr/02-sonataflow_platform.yaml
Outdated
Show resolved
Hide resolved
de33edd
to
7b43534
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have left some minor comments, good job! thanks.
test/testdata/platform/persistence/generic_from_platform_cr/02-sonataflow_platform.yaml
Outdated
Show resolved
Hide resolved
test/testdata/platform/persistence/overwritten_by_services/02-sonataflow_platform.yaml
Outdated
Show resolved
Hide resolved
...stdata/workflow/persistence/from_platform_overwritten_by_service/02-sonataflow_platform.yaml
Outdated
Show resolved
Hide resolved
f0585cf
to
22640ef
Compare
@jordigilh can you please rebase since we've merged the global platform PR? |
@jordigilh look like we need some love to fix merge conflicts 😿 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added some more comments, many thanks @jordigilh
@@ -157,7 +159,13 @@ func defaultContainer(workflow *operatorapi.SonataFlow) (*corev1.Container, erro | |||
if err := mergo.Merge(defaultFlowContainer, workflow.Spec.PodTemplate.Container.ToContainer(), mergo.WithOverride); err != nil { | |||
return nil, err | |||
} | |||
defaultFlowContainer = ConfigurePersistence(defaultFlowContainer, workflow.Spec.Persistence, defaultSchemaName, workflow.Namespace) | |||
if workflow.Spec.Persistence != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please correct me if I'm wrong, but believe this code is not considering the case where the workflow don't have a configured persistence, but the platform has. In that case, we should try to get it from the platform.
I am correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are 3 scenarios managed here:
- Persistence field in the workflow spec is nil: If the persistence field is nil, then the workflow will have no persistence at all.
- Persistence is empty (
{}
): Persistence will be pull from the platform if it exists. - Persistence is populated: Use the one in workflow.
Let me know if that makes sense in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense. But what about adding a label to address this problem sonataflow.org/persistence=platform|workflow|none
, defaults to none.
The problem with using this approach, @jordigilh @tchughesiv is that the API is not communicating what will be done. It's an error prune having .spec.persistence: {}
meaning that we will pull from the platform.
On the other hand, having .spec.persistence: <data>
clears communicate that we are overriding. But .spec.persistence: {}
or not having this attribute defined is dubious IMO. One can interpret that it will pull from platform if the attribute is not there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually there is the enabled
field in the service that is set to true if the service is defined (not nil) by the operator. It's something we're doing already in that sense: define an empty service for DI and the operator will populate it with the default configuration, in this case enabled=true
.
I'm fine using labels as well. Consistency is important at the end, so if labels/annotations is the path forward for these cases, then this should be the approach accross whenever facing these situations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd look at this as:
- No persistence configured:
.spec.persistence: {}
- Sets explicitly the empty value for persistence.
- Use workflow's persistence configuration:
.spec.persistence: <data>
- Use the system/platform default:
.spec.persistence: nil
- By omitting this, the decision is propagated to platform/cluster
+1 for consistency (always).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if persistence is
nil
in the workflow, settings are used from platform CR.
Doesn't that break backwards compatibility? I mean, currently a workflow that doesn't have the persistence field populated is not expecting to have persistence if the platform contains one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if persistence is
nil
in the workflow, settings are used from platform CR.Doesn't that break backwards compatibility? I mean, currently a workflow that doesn't have the persistence field populated is not expecting to have persistence if the platform contains one.
what do you mean by currently
? isn't this PR introducing this capability and we get to define how it functions? how would this break backwards compatibility?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Be
if persistence is
nil
in the workflow, settings are used from platform CR.Doesn't that break backwards compatibility? I mean, currently a workflow that doesn't have the persistence field populated is not expecting to have persistence if the platform contains one.
what do you mean by
currently
? isn't this PR introducing this capability and we get to define how it functions? how would this break backwards compatibility?
Because if we define that when persistence is nil, which is the default value, then it should derive the persistence from the platform if it´s defined, then workflows that are currently running without persistence (the ones before merging this PR), will suddently now inherit persistence from the platform even though they don´t require it.
That´s what I mean by backwards compatibility:
- Currently
persistence=nil
means no persistence, it matches the behavior that the workflows expect before this PR is merged - After this PR is merged, then
persistence=nil
means it might have persistence depending on the platform, whether the workflow requested it or not.
I think that if we have a way to discern if the workflow requires persistence or not, regardless of the value of the persistence struct, we will save ourselves all this trouble and just apply what needs to be applied.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- After this PR is merged, then
persistence=nil
means it might have persistence depending on the platform, whether the workflow requested it or not.
but it won't, because existing platform CRs won't have the spec.persistence
field set. this PR is introducing it as a new field. hence, existing workflows won't inherit persistence unless the user decides to enable it either within the workflow or the existing platform. we should be good to go, no backwards compat issues.
return nil, fmt.Errorf("no persistence specification available in the workflow or in the platform") | ||
} | ||
if config.PostgreSQL != nil { | ||
p = config.PostgreSQL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the workflow persistence was set, we need to give the chance to see if a schema was provided, and if it's provided, below we must use that schema instead of the defaultSchema that we receive as parameter.
In this way we give users the chance to fine tune the schema name for a particular workflow.
if config.PostgreSQL != nil { | ||
p = config.PostgreSQL | ||
} else if persistence.WorkflowConfig.GetPostgreSQLConfiguration() != nil { | ||
p = persistence.WorkflowConfig.GetPostgreSQLConfiguration() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we pick the platform configuration, yes, we must use the defaultSchema as it comes, basically the workflow name.
22640ef
to
e407a8d
Compare
e407a8d
to
071796c
Compare
f61ee98
to
95b390b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@@ -157,7 +159,13 @@ func defaultContainer(workflow *operatorapi.SonataFlow) (*corev1.Container, erro | |||
if err := mergo.Merge(defaultFlowContainer, workflow.Spec.PodTemplate.Container.ToContainer(), mergo.WithOverride); err != nil { | |||
return nil, err | |||
} | |||
defaultFlowContainer = ConfigurePersistence(defaultFlowContainer, workflow.Spec.Persistence, defaultSchemaName, workflow.Namespace) | |||
if workflow.Spec.Persistence != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense. But what about adding a label to address this problem sonataflow.org/persistence=platform|workflow|none
, defaults to none.
The problem with using this approach, @jordigilh @tchughesiv is that the API is not communicating what will be done. It's an error prune having .spec.persistence: {}
meaning that we will pull from the platform.
On the other hand, having .spec.persistence: <data>
clears communicate that we are overriding. But .spec.persistence: {}
or not having this attribute defined is dubious IMO. One can interpret that it will pull from platform if the attribute is not there.
test/testdata/workflow/persistence/by_service/02-sonataflow_platform.yaml
Show resolved
Hide resolved
…nataflow CRDs Signed-off-by: Jordi Gil <[email protected]>
…sistence configuration when they don't provide one. Services will always default to use persistence when available either within their spec or defined in the platform's. Workflows, on the other hand, can use the platform's persistence configuration by defining an empty persistence struct in their CR. Otherwise they can populate the structure with the service references Signed-off-by: Jordi Gil <[email protected]>
…wn provided configuration or one derived from the platform Signed-off-by: Jordi Gil <[email protected]>
…void requiting to provide it when the service is co-located to the sonataflow CR Signed-off-by: Jordi Gil <[email protected]>
…e persistence configuration Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
…dPropsAndSpecAndGeneric fails Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
…tests Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
…URL string and dataSchema in the configuration to be inherited by the workflows. Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
…ect persistence configuration when platform provides one Signed-off-by: Jordi Gil <[email protected]>
… came in by accident Signed-off-by: Jordi Gil <[email protected]>
… before processing the postgreSQL configuration Signed-off-by: Jordi Gil <[email protected]>
Signed-off-by: Jordi Gil <[email protected]>
… in workflow so that when deriving the persistence from the platform, to generate the schema using the workflow's name Signed-off-by: Jordi Gil <[email protected]>
… operator to derive the persistence from the platform if available, and persistence = {} to instruct the operator to discard persistence in the workflow, even when the platform has one Signed-off-by: Jordi Gil <[email protected]>
5c4d907
to
8281d2c
Compare
…n RetrievePersistence()
257bc03
to
4ff3d70
Compare
@jordigilh can you check the code gen? |
Signed-off-by: Jordi Gil <[email protected]>
4ff3d70
to
9865cca
Compare
Adds a new field in the SonataflowPlatform
Spec
struct to allow defining a shareable postgreSQL persistence configuration for workflows and to platform services:https://github.com/jordigilh/incubator-kie-kogito-serverless-operator/blob/7f96442d27ae773d23cab74e84423b069dfe2f90/api/v1alpha08/sonataflowplatform_types.go#L49-L53
This configuration is inherited by workflows that require persistence when the persistence field in the workflow spec is initialized as empty.
https://github.com/jordigilh/incubator-kie-kogito-serverless-operator/blob/ee06ddd88a03658dace236574108c2f446454186/controllers/profiles/common/object_creators_test.go#L383-L385
When both workflow CR and platform CR contain persistence, the workflow CR specification will take precedence.
Persistence in the workflow can be configured using these scenarios:
persistence
field is not nil, the operator will use its configuration. If the configuration is empty (e.g.{}
, then no persistence is set for the workflow)Persistence
field is nil, the operator will derive the persistence from theSonataFlowPlatform
CR'spersistence
field, if it exists. Otherwise no persistence is provided.Extends e2e tests in these cases:
Persistence
spec, ignoring the one provided by the platform CR.{}
Persistence
field in theSpec
.@ricardozanini @wmedvede @tchughesiv @domhanak PTAL.